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Executive  Summary 


\  DLA  PREPROVISIONING  PROTOTYPE:  A  SUCCESSFUL  CALS 
\  DEMONSTRATION  PROJECT 

The  most  significant  problem  in  the  provisioning  process  is  missing  or 
inadequate  technical  data  —  the  early  use  of  the  Preprovisioning  Prototype  (PPP) 
helps  solve  the  problem.  It  does  this  by  identifying  technical  data  deficiencies  early 
enough  in  the  process  so  that  the  contractor  can  correct  them  before  provisioning 
team  members  review  item  information  with  the  item  manager  and  the 
manufacturer.  The  PPP  also  improves  Defense  Logistics  Agency  (DLA)  review  of 
provisioning  data  received  from  the  Military  Services  and  their  contractors,  shortens 
the  data  review  cycle,  improves  tracking  of  work  assignments  as  well  as  technical 
and  provisioning  data,  increases  data  integrity,  and  increases  information 
accessibility,  j 

The  PPP  project  demonstrated  that  significant  opportunities  exist  within 
Computer-aided  Acquisition  and  Logistic  Support  (CALS)  to  streamline  provisioning 
and  cataloging  processes.  Because  of  the  benefits  derived  from  the  PPP,  we 
recommend  that  DLA  immediately  expand  the  demonstration  project  to  provide  a 
full  production  capability.  We  also  recommend  a  comprehensive  modernization  of 
the  provisioning  process  —  consistent  with  the  CALS  environment.  Such 
modernization  would: 

•  Reduce  DLA  procurement  administrative  leadtime  support  to  the  Services. 

•  Shorten  the  provisioning  research  process. 

•  Assist  in  and  simplify  the  provisioning  decision-making  process. 

•  Decrease  the  amount  of  time  and  effort  for  provisioning  source  coding 
conferences. 

•  Facilitate  electronic  processing  of  Service  supply  support  requests. 

DLA  should  establish  a  Provisioning  Integration  Center  as  the  focal  point  to 
modernize  the  provisioning  process.  DoD  could  use  the  Center  as  part  of  the  CALS 
Testbed  Network  and  to  develop  and  validate  proposed  provisioning  enhancements 
of  CALS  and  other  logistics  modernization  efforts. 
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CHAPTER  1 


INTRODUCTION 

BACKGROUND 

The  DoD  Computer-aided  Acquisition  and  Logistic  Support  (CALS)  initiative  is 
directed  toward  improving  the  design,  development,  and  support  of  weapon  systems 
through  the  use  of  current  and  emerging  computer  technology.  CALS  emphasizes 
greater  utilization  of  information  contained  in  DoD  and  contractor  databases  to 
provide  optimal,  economic  weapon  system  support.  The  Defense  Logistics  Agency 
(DLA)  believes  that  provisioning  for  new  weapon  systems  could  benefit  substantially 
from  greater  application  of  CALS  technology. 

Provisioning  is  a  logistics  management  process  for  determining  and  acquiring 
the  range  and  quantity  of  support  items  (i.e.,  spares  and  repair  parts,  special  tools, 
test  equipment,  and  support  equipment)  necessary  to  operate  and  maintain  an  end 
item  of  material  for  an  initial  period  of  service.  The  provisioning  goal  is  to  ensure 
timely,  adequate,  and  economical  support  of  systems  and  equipment  entering 
Service  inventories. 

More  complete  access  to  the  Military  Services’  databases  prior  to  conferences 
on  provisioning  source  coding  could  improve  the  timeliness  and  accuracy  of  weapon 
system  support  during  initial  fielding  and  provide  DLA  early  visibility  of  the 
complete  range  of  data  elements  needed  to  better  manage  spare  parts.  (At  provision¬ 
ing  source  coding  conferences,  provisioning  team  members  review  item  information 
with  the  item  manager  and  the  manufacturer.)  With  access  to  those  databases,  DLA 
and  the  Services  can  avoid  unproductive  delays  by  making  as  many  correct  decisions 
regarding  these  items  as  early  in  the  provisioning  process  as  possible.  An  automated 
preprovisioning  process  will  also  allow  DLA  and  the  Services  to  transmit  data  to 
contractors  for  review  of  changes  before  the  conference  so  that,  at  the  conference, 
discussion  can  be  limited  to  those  items  for  which  discrepancies  exist  or  additional 
information  is  needed. 
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PREPROVISIONING  PROTOTYPE  DEMONSTRATION  PROJECT 


The  DLA  Preprovisioning  Prototype  (PPP)  is  a  CALS  project  to  demonstrate 
the  capabilities  and  benefits  available  from  on-line  access  to  automated  provisioning 
source  coding  data  in  the  Services’  logistics  databases. 

The  demonstration  project  was  established  to  verify  the  ability  of  the  PPP  to 

•  Facilitate  DLA  inventory  control  point  (ICP)  review  of  provisioning  data 
received  from  the  Services  and  contractors  in  preparation  for  provisioning 
source  coding  conferences 

•  Eliminate  data  duplication  and  identify  opportunities  for  use  of  common 
hardware  and  software  components 

•  Accommodate  functional  integration  and  data  sharing  with  industry  and 
the  Services. 

The  PPP  was  selected  as  a  CALS  demonstration  project  to  determine  the  ways 
in  which  automation  could  facilitate  DLA  ICP  entry  of  provisioning  data  received 
from  the  Air  Force  and  their  designated  contractor  in  preparation  for  provisioning 
source  coding  conferences. 

For  the  PPP  demonstration  project,  DLA  and  the  Air  Force  agreed  to  use  an 
ongoing  procurement  to  obtain  applicable  provisioning  and  technical  data.  In  DLA, 
the  Defense  Applied  Information  Technology  Center  (DAITC)  provided  computer 
and  telecommunications  support,  with  the  computer  housed  at  Pleasanton,  Calif., 
and  access  to  it  available  through  standard  DLA  Z-248  microcomputers  running  a 
personal  computer  (PC)  communications  software  package  and  a  1200-baud  modem. 
The  Defense  Construction  Supply  Center  (DCSC)  and  the  Defense  Industrial  Supply 
Center  (DISC)  provided  operational  support  in  processing  the  applicable  provision¬ 
ing  and  technical  data. 

CONCLUSIONS  AND  RECOMMENDATIONS 

Using  the  PPP  automated  system  early  in  the  provisioning  process  is  a  signif¬ 
icant  step  toward  resolving  the  most  serious  problem  in  the  process  —  missing  or 
inadequate  technical  data.  In  the  demonstration,  the  PPP  solved  that  problem  by 
allowing  DLA  to  identify  technical  data  deficiencies  early  enough  for  the  contractor 
to  correct  them  before  the  provisioning  source  coding  conference. 


The  demonstration  project  also  verified  the  following  additional  near-term 
benefits  associated  with  the  PPP: 

•  Shortened  Review  Cycle.  The  PPP  shortens  the  time  required  to  review 
provisioning  data  submitted  to  DLA  from  the  Air  Force  Air  Logistics 
Centers  (ALCs)  by  eliminating  the  preparation  and  shipment  of  manual 
forms.  The  DLA  ICPs  receive  data  in  electronic  form  from  the  ALCs  for 
review  prior  to  the  source  coding  conference.  In  addition,  DLA  technicians 
are  able  to  access,  view,  scroll,  and  update  provisioning  data  on  a  terminal 
screen  located  at  their  workstations. 

•  Improved  Tracking  and  Updating.  The  PPP  improves  the  process  of 
tracking  the  flow  of  technical  data  and  work  assignments  and  the  progress 
of  tracking  provisioning  data.  It  maintains  an  electronic  audit  trail  for  each 
transaction. 

•  Increased  Data  Integrity.  The  use  of  common  data  definitions  and  data 
formats  facilitates  data  exchange  between  DLA  ICPs  and  the  Air  Force.  It 
also  contributes  to  streamlined  updating  procedures. 

•  Increased  Information  Accessibility.  Managers  and  technicians  working  in 
the  provisioning  area  find  both  the  technical  and  statistical  data  more 
accessible  and  accurate.  The  electronic  display  of  management  and  statisti¬ 
cal  data  is  tailored  to  the  DLA  ICPs’  needs. 

In  the  near-term,  \<e  recommend  the  PPP  system  be  expanded  and  placed  in 
full  production. 

In  the  mid-  and  long-term,  we  recommend  the  evolving  CALS  environment 
establish  a  framework  for  comprehensive  modernization  of  the  provisioning  process 
to  provide  the  following  benefits: 

•  It  will  reduce  procurement  administrative  leadtime  (PALT)  support  to  the 
Services. 

•  It  will  shorten  the  provisioning  research  process. 

•  It  will  assist  and  simplify  the  provisioning  decision-making  process. 

•  It  will  decrease  the  amount  of  time  and  effort  for  provisioning  source  coding 
conferences 

•  It  will  facilitate  processing  Service  supply  support  requests  electronically. 
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Overall,  the  PPP  demonstration  project  showed  that  the  use  of  computer 
technology  within  the  provisioning  process  affords  a  significant  opportunity  to 

•  Improve  productivity  and  increase  the  effectiveness  of  DLA  operations  to 
support  the  Services  and  other  Defense  agencies 

•  Capitalize  on  emerging  CALS  data  exchange  standards  and  other  ongoing 
CALS  initiatives  to  streamline  the  provisioning  and  cataloging  process. 

We  recommend  a  Provisioning  Integration  Center  (PIC)  be  established  as  the 
focal  point  to  streamline  and  integrate  the  provisioning  process.  The  PIC  will  serve 
as  part  of  the  CALS  Testbed  Network  and  will  develop  and  validate  proposed 
provisioning  enhancements  of  CALS  and  other  logistics  modernization  efforts. 


CHAPTER  2 


THE  CURRENT  PROVISIONING  ENVIRONMENT 


Provisioning  is  a  management  process  through  which  the  Services  determine 
and  acquire  the  range  and  quantity  of  support  items  (i.e.,  spares  and  repair  parts, 
special  tools,  test  equipment,  and  support  equipment)  necessary  to  operate  and 
maintain  a  weapon  system  or  end  item  for  an  initial  period  of  service.  The 
provisioning  goal  is  to  ensure  timely,  adequate,  and  economical  support  of  systems 
and  equipment  entering  Service  inventories.  DLA  involvement  in  provisioning 
includes  two  major  functions:  technical  management,  i.e.,  item  identification  and 
item  entry  control;  and  item  management,  i.e.,  inventory  control  and  requirements 
forecasting. 

Increasingly  long  leadtimes,  diminished  sources  of  supply,  a  need  for  parts  not 
now  in  production,  and  the  uncertainty  in  requirements  are  factors  that  complicate 
DLA  provisioning  support.  However,  missing  or  inadequate  technical  data  on 
support  items  is  considered  to  be  the  single  largest  problem  in  the  provisioning 
process.  Timely  availability  of  accurate  technical  data  (engineering  drawings, 
manufacturer’s  drawings  parts  lists,  specifications,  etc.)  is  a  key  ingredient  for 
greatly  compressing  both  administrative  and  manufacturing  leadtimes.  The  PPP  is 
targeted  at  shortening  the  technical  data  evaluation  process,  which  includes 
identifying  missing  or  inadequate  data,  obtaining  those  data,  and  validating  the 
data  to  facilitate  technical  decision  making. 

The  current  provisioning  process  is  illustrated  in  Table  2-1.  (The  column 
headings  show  the  number  of  months  allocated  to  complete  all  actions  in  a  column. 
The  numbers  in  parentheses  indicate  the  sequence  in  which  the  actions  occur.)  The 
Service  receives  provisioning  technical  documentation  (PTD)  from  the  contractor.  It 
includes  the  Provisioning  Parts  List  (PPL),  provisioning  screening  results  (PSR), 
and  supplementary  provisioning  technical  documentation  (SPTD).  The  PPL 
contains  all  items  making  up  a  weapon  system  or  end  item.  It  can  be  structured  at 
the  end  item,  component,  or  assembly  level  as  specified  by  the  provisioning  activity. 
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CURRENT  PROVISIONING  PROCESS 
(Part  number  supply  support  request) 
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The  PPL  format  and  documentation  requirements  are  defined  in  Military 
Standard  (MIL-STD)-1388-2A  [Logistic  Support  Analysis  (LSA)-036,  Provisioning 
Requirements]  or  MIL-STD-1552A  ( Military  Standard  Provisioning  Technical 
Documentation)  for  existing  (pre-MILrSTD-1388-2A)  contracts.  Data  requirements 
are  tailored  for  each  contract.  The  data  elements  required  are  specified  by  the 
requiring  activity  on  DD  Form  1949-1,  PTD  Data  Selection  Sheet ,  and  represent  a 
subset  of  1388-H  and  HI  records.  SPTD  provides  the  technical  data  used  to  describe 
an  item;  it  includes  specifications,  standards,  drawings,  photographs,  sketches,  and 
descriptions.  MIL-STD-1561B  ( Military  Standard  Provisioning  Procedures, 
Uniform,  Department  of  Defense)  identifies  SPTD  requirements.  SPTD  is  required 
for  each  first-appearance  item  on  the  PPL  except  for 

•  Items  identified  by  a  Government  specification  or  standard  that  completely 
describes  the  items 

•  Items  recorded  in  the  Defense  Logistics  Services  Center  (DLSC)  Defense 
Integrated  Data  System  (DIDS)  (stocklisted  items)  with  a  full  description. 

PPL  and  PSR  data  are  loaded  into  a  database  for  validation  through  Service 
provisioning  systems.  If  any  items  require  correction,  the  PPL  tape  is  sent  back  to 
the  contractor.  After  the  tape  is  corrected,  the  process  continues;  it  includes  screen¬ 
ing  items  with  no  National  Stock  Numbers  (NSNs)  through  the  DIDS. 

The  data  obtained  from  reference  number  interrogations  of  DIDS  are  the  PSR. 
The  provisioning  screening  request  is  submitted  to  DLSC  by  the  contractor  (the 
contractor  is  encouraged  to  perform  DIDS  screening)  in  accordance  with  DoD  Manu¬ 
als  4100.38-M  ( Department  of  Defense  Provisioning  and  Other  Preprocurement 
Screening  Manual)  and  DI-V-7016  ( Provisioning  and  Other  Preprocurement 
Screening  Data).  The  Services  then  establish  a  provisioning  database  and  generate 
technical  review  documents  (PPL  reports)  for  use  at  source  coding  conferences.  The 
average  conference  lasts  approximately  a  week  and  reviews  about  10,000  line  items; 
however,  in  some  cases,  it  may  take  3  weeks  or  longer.  DLA  may  attend  the 
provisioning  conference  to  ensure  adequacy  of  the  SPTD  for  items  assigned  to  DLA 
for  item  management  and  assist  in  the  selection  and  computation  of  the  range  and 
quantity  of  support  items.  DLA,  however,  is  more  likely  to  attend  when  large 
numbers  of  DLA-managed  Federal  Supply  Class  (FSC)  items  are  involved.  For  the 
most  part,  DLA  is  not  involved  in  any  provisioning  source  coding  activities  prior  to 
the  source  coding  conference. 


The  purpose  of  the  source  coding  conference  is  to  give  provisioning  team 
members  the  opportunity  to  review  recommended  item  information  with  the  contrac¬ 
tor.  At  the  conference,  the  Government  selects  support  items  and  assigns  technical 
and  management  codes  to  them.  All  steps  up  to  this  point  are  referred  to  as  the 
technical  management  review  stage. 

After  the  conference,  the  Service  supply/provisioning  database  is  updated  and  a 
supply  support  request  (SSR)  list  is  generated  and  sent  with  supporting  technical 
data  to  DLA  for  review.  The  SSR  includes  all  known  manufacturers’  part  numbers 
(P/Ns),  contractor  commercial  and  Government  entity  (CAGE)  codes,  and  user 
requirements.  DLA  advises  the  Service  of  deficiencies  in  the  receipt  of  technical 
data  and  determines  the  quantity  of  the  item  to  be  stocked.  (Technical  data  may  not 
be  provided  for  a  number  of  valid  reasons.)  DLA  reviews  items  for  potential 
interchangeability  and  substitutability  (I&S)  with  currently  managed  items  and 
makes  recommendations  for  approval  or  disapproval  of  items  by  the  Service. 
Recommendations  for  substitutes  are  forwarded  to  the  Service.  The  functions 
performed  after  the  conference  are  referred  to  as  item  management  review. 
Approximately  58  percent  of  the  active  items  (common  piece  parts)  used  by  the 
Services  are  cataloged  and  managed  by  DLA  today.  Figure  2-1  displays  the  current 
DLA  SSR  processing  environment. 
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FIG.  2-1.  OLA  SSR  PROCESSING  ENVIRONMENT  -  CURRENT 


CHAPTER  3 


DLA  PREPROVISIONING  PROTOTYPE  DEMONSTRATION 

INTRODUCTION 

The  PPP  was  selected  as  a  CALS  demonstration  project  to  determine  ways  in 
which  automation  could  facilitate  DLA  ICP  item  entry  control  of  provisioning  data 
received  from  the  Air  Force  and  their  designated  contractor  in  preparation  for 
provisioning  source  coding  conferences. 

For  the  PPP  demonstration,  DLA  and  the  Air  Force  agreed  to  use  an  ongoing 
procurement  to  obtain  applicable  provisioning  and  technical  data.  In  DLA,  DAITC 
provided  computer  and  telecommunications  support  and  DCSC  and  DISC  provided 
operational  support  in  processing  the  applicable  provisioning  and  technical  data. 

DEMONSTRATION  COMPUTER  SYSTEM 

The  DLA  PPP  demonstration  database  and  system  software  were  housed  on  a 
DLA  DAITC  computer  in  Pleasanton,  Calif.  Access  to  that  computer  was  available 
through  standard  DLA  Z-248  microcomputers  running  a  PC  communications  soft¬ 
ware  package  and  a  1200-baud  modem. 

The  specific  machine  upon  which  PPP  ran  was  an  ELXSI  superminicomputer 
running  the  UNIX  operating  system.  The  system  used  the  UNIFY  Database 
Management  System  and  its  associated  program  ACCELL™  as  the  major  user 
interface. 

DEMONSTRATION  SYSTEM  DATA 

The  specific  database  residing  in  PPP  files  was  provided  by  the  Air  Force’s 
D220  system  for  a  specific  system  provisioning  project.  The  project,  a  utility  truck 
from  Oshkosh  Manufacturing  Co.,  resulted  in  a  demonstration  database  of  more 
than  4,200  different  parts  or  Provisioning  List  Item  Sequence  Numbers  (PLISNs). 
Using  the  PPP,  DLA  catalogers  actually  processed  these  PLISN  records  to  get  ready 
for  the  scheduled  provisioning  source  coding  conference.  Cataloger  progress  in 


working  the  PLISNs  was  tracked  through  the  Master  Contract  Matrix  (MCM)  file 
and  the  accompanying  reporting  capability. 

DEMONSTRATION  PREPROVISIONING  PROCESS 

The  PPP  demonstration  automated  most  of  the  manual  methods  and  proce¬ 
dures.  The  PPP  demonstration  was  tested  initially  at  DCSC  and  DISC,  and  key  DLA 
ICP  personnel  were  trained  to  use  the  system  at  DCSC. 

The  major  processes  performed  by  the  demonstration  and  the  relationship 
between  the  Air  Force  ALC,  Robins  Air  Force  Base,  Ga.,  and  DCSC/DISC  are 
depicted  in  Figure  3-1. 


MMk  PUCN  •  PUSN/PCCN/SCC  (Provisioning  list  item  Sequence  Number/Provisioning  Contract  Control  Number/Submission  Control  Code). 


FIG.  3-1.  DEMONSTRATION  PREPROVISIONING  PROCESSES 
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Upon  receipt  of  PPL  and  PSR  data  on  the  magnetic  tape  from  the  ALC,  the  PPP 
created  a  record  of  the  contract-identifying  information  in  an  MCM  file  and  a  record 
for  each  line  item  in  the  PLICN  [PLISN/Provisioning  Contract  Control  Number 
(PCCN)/Submission  Control  Code  (SCC)]  file.  Records  were  assigned  to  a  cataloger 
who  evaluated  the  quality  of  the  PTD  and  determined  whether  he/she  could 
adequately  review  it  in  the  allotted  time.  The  size  of  the  file  (number  of  items  with 
no  NSN),  validity  of  P/Ns,  and  availability  of  properly  sequenced  screening  results 
all  helped  determine  the  need  for  assigning  additional  personnel  and  obtaining 
DEDS  Total  Item  Record  (TIR)  screening. 

With  the  demonstration  system,  DCSC  and  DISC  catalogers  could  review  and 
update  file  data,  and  generate  management  statistical  reports  through  an  on-line, 
menu-driven  system.  All  data  were  edited  when  entered,  and  cross  edits  were 
performed  to  ensure  accuracy  and  quality  assurance  before  the  data  were  released  to 
the  ALC. 

Once  the  PLICN  records  were  updated  on-line  by  the  cataloger,  the  PLICN 
data  file  was  released  to  the  originating  ALC.  The  PPP  also  recorded  management 
information  and  transferred  released  records  and  selective  data  to  *jie  appropriate 
history  files. 

FUNCTIONS  PERFORMED  BY  PREPROVISIONING  PROTOTYPE 

The  PPP  performs  the  following  specific  functions: 

•  Establishing/ maintaining  MCM.  This  function  establishes  the  submission 
identification  data  file.  Each  record  in  the  MCM  is  established  by  either  the 
cataloger  or  the  PPP  during  the  validation  step  of  the  data  submitted  to 
DCSC.  The  cataloger  can  establish  this  record.  The  system  either 
completes  the  record  established  by  the  cataloger  or  builds  the  entire  data 
record  from  information  recorded  in  the  header  information  of  the  ALC- 
submitted  data.  The  cataloger  can  view,  query,  and  update  this  file  through 
an  on-line,  menu-driven  capability.  Interactive  and  off-line  updates  are 
also  made  to  this  file  as  a  result  of  interactive  and  off-line  processing  of  the 
PLICN  file.  The  appendix  contains  a  more  detailed  discussion  of  establish¬ 
ing  the  MCM. 

•  Establishing! maintaining  PLICN  record  data  file.  This  function  establishes 
records  in  the  PLICN  data  file  from  information  in  the  ALC-submitted  PPR 
file  (see  Figure  3-2). 


3-3 


FIG.  3-2.  ESTA8USH  PUCN  FILE 

Following  establishment  of  the  MCM  file  (assuming  the  file  is  not  a 
duplicate  submission),  the  PPP  establishes  a  separate  PLICN  record  for 
each  PLISN  received  and  adds  one  to  TOTAL  PLISNs  in  the  MCM  file. 

Each  PLICN  is  worked  by  a  cataloging  technician.  This  consists  of 
reviewing  and  annotating  or  correcting,  as  necessary,  each  PLICN.  The 
PLICN  assignment  can  be  made  directly  by  the  supervisor,  or  the  cataloger 
can  request  a  work  assignment  directly  from  the  PPP.  In  the  latter  case,  the 
next  unassigned  PLICN  is  selected. 

The  cataloger  has  an  on-line  capability  to  annotate  or  correct  as  necessary 
the  following  data  elements: 

►  FSC 

►  CAGE 
t  P/N 

►  Reference  number  category  code  (RNCC) 

►  Item  name 

p  Quantity  unit  pack  (QUP) 

►  Unit  of  issue  (U/I) 

►  Price 

►  N ational  Item  Identification  N umber  (NIIN) 

►  Document  availability  code  (DAC). 


•  Suspense  and  tracking.  The  PPP  tracks  both  the  overall  file  and  all  its 
records.  It  notifies  the  cataloger  when  the  responsible  cataloger  for  a  PPL  is 
recorded  and  when  the  PPL  due  date  is  breached. 

•  Accounting.  The  accounting  function  continuously  updates  backlog  and 
production  statistics  for  display.  The  function  tracks  statistics  for  both  the 
overall  PUCN  record  and  individual  PLICN  data  elements. 

CATALOGER  WORKLOAD  MENU 

The  cataloger  workload  menu  displays  the  eight  processing  options  (routines) 
described  in  the  following  sections: 

•  Option  1  (Records  Awaiting  Remote  Screening/ Research).  Option  1  of  the 
workload  menu  displays  key  information  from  the  MCM  for  PLICN  records 
requiring  technician  review. 

The  cataloger  is  prompted  for  the  contract  number  identification  code 
(CNID)  or,  if  the  cataloger  does  not  know  it,  for  the  Procurement  Instru¬ 
ment  Identification  Number  (PIIN)/PCCN/SCC.  Failure  to  answer  these 
questions  forces  the  PPP  to  route  the  user  to  the  MCM  file  and  display  all 
contracts  in  due-date  order  on  an  MCM  screen. 

When  a  specific  contract  is  identified,  the  system  requests  the  specific 
PLICN  for  initial  display.  If  that  request  is  unanswered,  the  PLICNs  are 
presented  sequentially  in  PLICN-sort  order,  using  a  PLICN  screen. 

To  minimize  screen  updates,  these  system  prompts  and  responses  are 
handled  within  the  Commands,  Messages,  and  Help  area. 

Once  the  detailed  PLICN  screen  is  presented,  the  cataloger  can  add  or 
update  information  for  any  field,  move  to  other  PLICN  records,  switch  to  the 
MCM  screen,  or  return  to  the  initial  menu.  This  dialog  is  either  command- 
or  function-key-driven  using  the  provided  Commands,  Messages,  and  Help 
area. 

The  data  entered  by  the  cataloger  is  edited.  When  the  cataloger  completes 
PLICN  review/processing,  the  PPP  verifies  the  data  and  automatically 
performs  the  following  actions: 

t  Moves  the  FSC  originally  recorded  to  the  Contractor  Original  PPL  FSC 
field  and  inserts  the  new  (corrected)  FSC  in  the  FSC  field. 

t  Displays  the  nest  record  in  suspense  if  the  CAGE  and  reference  numbers 
are  identical. 

►  Displays  the  MCM  maintenance  screen  to  record  MCM  statistics  if  the 
CAGE  and  reference  numbers  differ. 


3-5 


•  Option  2  (FSC  Assignment/Resolution).  Option  2  of  the  workload  menu 
allows  the  cataloger  to  enter  the  FSC  on  nonstocklisted  items  that  are  not 
assigned  an  FSC  code  by  the  contractor  in  the  preparation  of  the  PPL. 

•  Option  3  (Drawing  Adequacy  Review).  Option  3  of  the  workload  menu 
allows  the  cataloger  to  input  drawing  information. 

•  Option  4  (Final  Review).  Option  4  of  the  workload  menu  allows  the  tech¬ 
nician  to  perform  a  final  review  of  records.  This  situation  occurs  when  a 
cataloger  technician  code  (CTC)  is  recorded  on  a  PLICN  record  and  the 
corresponding  cataloging  technician  makes  a  change  in  the  recorded  NSN 
and/or  reference  number. 

•  Option  5  (Delinquent  Items).  Option  5  of  the  workload  menu  displays  the 
backlog  of  delinquent  items  for  a  particular  FSC.  All  items  overdue  per 
PUCN  record  due  date  (from  MCM)  are  displayed.  Catalogers  can  only 
display  overdues  applicable  to  their  cognizant  work  assignments,  while  the 
supervisor  can  review  overdues  for  the  department  or  individual  catalogers. 

•  Option  6  (Files  Interrogation).  Option  6  of  the  workload  menu  allows  the 
cataloger  technician  to  interrogate  system  files  by  P/N,  CAGE/P/N,  PLICN, 
orNIIN. 

•  Option  7  (Part  Number  Screening).  For  purposes  of  the  demonstration,  we 
assume  that  the  ALC  completed  DIDS  P/N  screening  prior  to  submitting  the 
data  to  DCSC.  However,  the  cataloger  has  the  capability  to  simulate 
screening  of  selected  records. 

•  Option  8  (Exit  Program).  Option  8  allows  the  technician  to  discontinue  all 
processing  and  sign  off  the  PPP. 

PREPROVISIONING  DEMONSTRATION  EVALUATION 

The  single  most  important  conclusion  reached  in  demonstrating  the  PPP  was 
that  preprovisioning  data  can  be  processed  in  advance  of  source  coding  conferences 
and  well  in  advance  of  receiving  an  SSR  from  the  Air  Force.  Advanced  processing  of 
the  technical  data  used  for  provisioning  permits  determination  of  its  adequacy  for 
developing  complete  item  identification.  Moreover,  when  technical  data  are  missing 
or  inadequate,  there  is  still  sufficient  time  to  notify  and  obtain  those  data  from  the 
contractor. 

The  PPP  demonstration  served  two  other  key  purposes:  first,  it  was  a  focal 
point  for  refining  and  defining  user  requirements  and  second,  it  substantiated  the 
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premise  that  increases  in  productivity  can  be  realized  through  smart  application  of 
computer  technology. 

Users'  Requirements 

The  PPP  demonstration  satisfied  the  functional  requirements  identified  during 
development  and  implementation.  During  DCSC  and  DISC  processing  of  the 
PLICNs  in  the  demonstration  database,  users  suggested  the  following  PPP 
enhancements  and  extensions: 

•  Quick  look-up  capability.  A  quick  look-up  capability  should  be  provided  to 
allow  the  catalogers  to  reference  another  PLICN  during  processing  of  their 
selected  PLICN.  Windowing  techniques  could  be  used  to  accommodate  this 
quick  look-up  search-and-retum  requirements. 

•  PLICN  assignment  and  access.  PLICN  assignment  and  access  should  be 
modified  such  that: 

k  PLICNs  are  assigned  automatically  to  cognizant  Defense  Supply  Centers 
(DSCs)  using  designated  FSCs. 

►  Catalogers  are  allowed  access  to  PLICNs  assigned  to  other  catalogers. 

►  Catalogers  are  allowed  to  add  new  PLICNs  as  required. 

•  Redefined  manager  functions.  Manager  functions  should  be  made 
consistent  with  DSC  operating  procedures.  In  the  demonstration 
environment,  the  PPP  provided  greater  management  control  of  PLICN 
assignment  and  review  than  is  necessary  in  a  production  environment. 

•  Redundant  data  storage  elimination.  The  database  design  should  be 
modified  to  ensure  that  the  data  are  stored  only  once,  but  can  be  displayed 
where  and  when  required.  The  following  two  examples  of  this  condition 
were  noted  during  the  demonstration: 

►  Both  the  MCM  and  PLICN  contain  the  CNTD,  PEN,  PCCN,  and  SCC. 
Since  the  CNID  is  a  unique  identifier  for  the  PEN,  PCCN,  and  SCC,  it  is 
the  only  field  that  needs  to  be  stored  as  part  of  the  PLICN.  All  fields 
could,  however,  be  displayed  on  the  PLICN  screen. 

t  The  ALC  field  is  represented  by  the  first  character  of  the  PCCN  field. 
Here,  also,  the  principal  of  single  storage  and  multiple  display  applies. 

•  DLSC  DIDS  interface  implementation.  An  interface  should  be  established 
directly  with  the  DLSC  DIDS  database  to  provide  users  with  access  to  P/N 
data  on  remote  computers  in  order  to  compare  preprovisioning  data  with 
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those  data  in  the  D1DS  database.  The  demonstration  only  simulated  access 
to  DIDS. 

•  Z-STEM  communications  software  use.  Z-STEM  communications  software 
is  an  appropriate  package  for  the  PPP  and  should  be  used.  It  is  standard, 
inexpensive,  widely  used,  and  supports  downloading  from  a  remote  central 
processing  unit  for  local  printing.  Z-STEM  was  successfully  tested  during 
the  demonstration;  however,  it  was  not  incorporated  at  the  time  of 
implementation. 

•  Hardware  configuration  source  selection.  The  DATTC-provided  ELXSI 6400 
host  computer  was  available  for  use  solely  during  the  development,  testing, 
and  implementation  of  the  PPP  demonstration  system.  Implementation  of  a 
full  production  capability  requires  an  alternative  host  computer. 

•  Simultaneous  processing  of  multiple  contracts.  Procedures  need  to  be 
implemented  to  allow  multiple  provisioning  weapon  system  contracts  to  be 
processed  simultaneously.  For  the  demonstration,  only  a  single  provision¬ 
ing  contract  was  processed. 

•  Screen  layout  modification.  Screen  layouts  should  be  reviewed  to  ensure 
they  accommodate  ready  access  to  the  most  worked  data  fields. 

•  Data  transmission  speed  improvement.  High-speed  access  [9600  bits  per 
second  (bpr)  or  above]  should  be  utilized  in  a  production  environment  to 
preclude  delays  in  screen  painting  and  cataloger  operations. 

•  Tape  Loading  Procedure  Expansion.  Procedures  implemented  during  the 
demonstration  accommodate  only  one  tape  per  contract.  Procedures  must 
be  expanded  to 

t  Allow  additional  tapes  for  existing  contracts 
►  Prevent  reloading  of  the  same  tape. 

•  Database  security  enhancement.  A  complete  log-in  and  password  security 
system  should  be  utilized.  For  the  demonstration,  the  CTC  entered  was 
accepted  without  elaborate  checks. 

•  Reports  and  management  information  expansion.  Reports  and  management 
information  should  be  provided  to  better  track  the  status  of  PPP  files  and 
evaluate  contractor  provisioning  performance. 
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Productivity  Enhancements 

Provisioning  Technical  Management 

PPP  is  a  focused  effort  targeted  at  item  entry  control  functions;  it  is  part  of  the 
technical  management  review  process  preparatory  to  provisioning  source  coding 
conferences  and  generation  of  SSRs.  Proactive1  technical  review  in  the  early  phases 
of  the  provisioning  process  provides  the  opportunity  for  DLA  ICP  catalogers  to  take 
the  following  actions: 

•  Screen  out  duplicate  items  by  thoroughly  comparing  the  submitted  items 
with  known  (NSN-assigned)  items 

•  Identify  opportunities  for  item  I&S  with  currently  managed  items  before 
receiving  an  SSR 

•  Develop  full  descriptive  item  identification  for  more  items  after  SSR  receipt 
by  acquiring  more-accurate  technical  data  prior  to  the  SSR  60-day  process¬ 
ing  time. 

Initiating  the  technical  management  process  early  in  the  provisioning  cycle 
offers  the  following  near-term  advantages: 

•  It  provides  the  Services  with  more-accurate  data  with  which  to  determine 
provisioning  requirements. 

•  It  provides  the  opportunity  to  obtain  missing  drawings  and/or  adequate 
technical  data  from  contractors. 

•  It  accelerates  source  coding  at  provisioning  conferences. 

•  It  leverages  I&S  opportunities. 

Provisioning  Item  Management 

PPP  prototyping  and  evaluation  highlighted  that  missing  and  inadequate 
technical  data  (PTD  and  SPTD)  are  the  biggest  impediments  to  the  provisioning 
process.  Accurate,  comprehensive  preprovisioning  starting  well  before  the  provi¬ 
sioning  conference,  provides  an  opportunity  to  reduce  PALT  by  identifying  and 
correcting  technical  data  deficiencies  early.  Moreover,  an  early  DLA  role  in  the 
provisioning  process  also  serves  a  precataloging  function.  Item  entry  control 


1 Proactive  is  a  coined  word  used  analogously  to  reactive  (responsive  to  a  stimulus);  proactive 
means  responsive  in  advance  of  any  stimulus.  .  . 
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provides  a  foundation  for  accurate  requirements  forecasting  and  submission  of 
requirements  to  DLA  by  the  Services. 

Other  Provisioning  Issues 

Discussions  with  DLA,  the  Services,  and  industry  revealed  a  range  of  diverse 
issues  regarding  provisioning  data  availability  and  data  management.  In  general, 
those  issues  centered  on  the  gaps  in  both  process  and  time  that  are  associated  with 
sequential  processes  currently  employed.  Those  gaps,  primary  targets  of  the  DoD 
CALS  initiative,  are  portrayed  in  Figure  3-3  as  they  apply  to  the  provisioning 
process. 


FIG.  3-3.  TECHNICAL  DATA  GAPS  IN  PROVISIONING 


The  discussions  identified  two  issues  that  represent  in  aggregate  the  provision¬ 
ing  issues  raised  during  preliminary  provisioning  assessment:  the  DLA  inventory 
growth  and  the  item  relationship  to  weapon  system. 


OLA  Inventory  Growth 

The  DLA  inventory  continues  to  grow  as  a  result  of  SSRs  from  the  Services 
despite  many  attempts  to  reduce  it.  The  growth  rate  has  averaged  5  percent  a  year 
over  the  past  5  years.  The  growth  problem  is  particularly  evident  with  first- 
appearance  items.  'An  estimated  30  percent  of  the  new  items  carried  in  inventory  in 
response  to  SSRs  received  from  the  Services  have  no  demand  after  4—5  years. 

For  some  selected  new  items  the  opposite  is  true.  Inaccurate  projections  of  true 
needs  create  a  substantial  volume  of  back  orders  that  clog  the  system  with  multiple 
inquiry  and  tracking  actions. 

Item  management  and  inventory  control  processes  are  based  upon  Service 
requirement  estimates.  The  Services  use  the  following  general  criteria  for  require¬ 
ments  determination: 

•  Stability  of  requirement.  The  minimum  need  is  expected  to  remain 
unchanged  or  vary  only  slightly  during  the  planned  contract  period. 

•  Stability  of  funding.  The  program  is  reasonably  expected  to  be  funded  at  the 
required  level  throughout  the  contract  period. 

•  Stable  configuration.  The  item  is  technically  mature;  has  completed 
research,  development,  test,  and  evaluation  (RDT&E);  relatively  few 
changes  in  design  are  anticipated;  and  underlying  technology  is  stable. 

•  Cost  confidence.  Contract  cost  estimates  appear  to  be  realistic. 

In  reality  these  criteria  are  not  routinely  met  and  the  Services,  working  with 
the  best  information  available,  generate  estimates  that  can  quickly  cause  inventory 
to  build  up.  This  problem  is  particularly  troublesome  in  initial  sparing.  Initial 
spares-demand-factors  are  based  on  engineering  reliability  estimates  of  failure  rates 
(derived  from  comparability  analysis)  and  sparing- to-availability  models. 

Early  in  the  development  cycle,  large  uncertainties  exist  in  the  predicted 
failure  rates  and  the  design  stability.  If  full  spares  are  provided  at  that  time,  the 
probability  is  high  that  a  large  number  will  ultimately  be  unusable  and  contribute  to 
unneeded  inventory. 

The  uncertainties  extant  during  the  time  in  which  actual  usage  data  is 
acquired  —  the  demand  development  cycle  —  cause  untimely  SSRs,  which 


3-1 1 


frequently  result  in  the  inability  to  meet  initial  fielding  schedules  without 
compensatory  accelerating  actions. 

The  essence  of  this  problem  is  that  DLA  currently  has  extremely  limited 
visibility  into  the  entire  body  of  engineering,  management,  budgetary,  and  policy 
implications  of  the  weapon  system  acquisition  process  that  precede  receipt  of  a 
Service  SSR.  Exploiting  the  PPP  in  this  role  could  provide  DLA  with  an  opportunity 
to  gain  such  visibility.  Near-term  opportunities  available  to  do  this  were  identified 
during  the  PPP  demonstration.  Data  contained  in  the  Air  Force  D220  Mechanized 
Provisioning  System  was  examined  to  determine  their  usefulness  to  DLA  catalogers 
and  provisioned.  These  candidate  data  items  are  shown  in  Table  3-1. 

Item  Relationship  to  Weapon  System 

Item  relationship  to  a  weapon  system  is  perhaps  the  fundamental  data  issue  in 
provisioning.  Currently,  establishing  the  basic  relationship  between  an  item  and  its 
associated  weapon  system  or  equipment  depends  on  the  Services’  submitting 
necessary  data  (weapon  system  designator  and  essentiality  codes)  in  the  SSRs. 
However,  the  information  in  the  SSR  is  submitted  only  when  establishing  an  initial 
need  for  an  item.  As  events  generally  experienced  in  the  life  cycle  of  a  weapon 
system  occur,  such  as  greater  than  anticipated  weapon  system  density,  no 
corresponding  increase  in  parts  stockage  level  occurs  because  the  weapon  system 
density  information  is  not  required  to  be  provided  to  DLA.  Additionally,  because  a 
time  lag  occurs  between  a  design  change  and  the  resulting  SSR  (see  Figure  3-3),  it  is 
not  sufficient  to  only  provide  DLA  with  visibility  to  design  changes  by  submittal  of 
an  SSR. 

Item  relationship  to  weapon  system  concerns  start  even  earlier  than  discussed 
above;  it  first  appears  in  the  Logistic  Support  Analysis  Record  (LSAR).  Existing 
software  for  automated  LSAR  limits  P/N  appearances  in  Support  Item  Identification 
Records  (H  and  HI  Data  Records).  Limiting  P/N  appearances  reduces  data  redun¬ 
dancy  but  makes  the  LSAR  H  and  HI  records  incompatible  with  current  computer- 
aided  design  (CAD)  and  configuration  status  accounting  techniques.  In  these  and 
many  other  engineering  functions  there  is  a  strong  move  to  record  and  maintain 
hierarchical  relationships  for  entire  platforms  and  systems.  Such  Top  Down 
Breakdown  (TDBD)  approaches  are  now  used  by  weapon  system  manufacturers  in 
provisioning. 
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TABLE  3-1 


CANDIDATE  DATA  ELEMENTS  TO  SUPPORT  EARLY  DLA  ITEM 
MANAGEMENT 

(Extracted  from  Air  Force  D220  Mechanized  Provisioning  System) 


Data  item 

Short  name 

Total  recommended  quantity 

TOT-RECOMD-QTY 

Initial  spare  support  list  candidate 

ISSL-PRNT 

Special  material  content  code 

TYPE-OF-ITEM  1 

Provisioning  list  category  code 

PLCC 

Special  maintenance  category  code 

TYPE-OF-ITEM  2 

Production  leadtime 

PROD-LEAD-TIME 

Maximum  allowable  operating  time 

MAX-ALL-OPER 

Maintenance  action  code 

MAINT-AC-CD 

Special  handling  code 

SPEC-HDLG-CD 

Weapon  system  code 

WPN-SYST-CD 

Programming  checklist  date 

PCL-DATE 

End  item  delivery  code 

EI-DEL-CD 

Percent  end  items  east 

EI-PCT-EAST 

Peak  month  program 

PK-MTH-PRG 

Type  of  program  code 

TYPE-PROG-CD 

Average  month  program 

AV-MNTH-PRG 

Number  of  bases 

NR-BASES 

Operational  need  date 

OPER-NEED-DT 

CAD  and  TDBD  provide  new  capabilities  in  identifying  mirror  image  (aircraft 
left  versus  right  wing  for  example)  requirements  mismatches  and  aggregating 
individual  piece  part  requirements  for  an  entire  platform.  These  areas  require  more 
analysis  and  are  discussed  further  in  Chapter  5. 
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CHAPTER  4 


NEAR-TERM  PROVISIONING  IMPROVEMENTS 


GENERAL 

Initial  use  of  the  PPP  demonstration,  extensive  interviews  with  participants  in 
the  PPP  development  effort,  and  review  of  the  DLA  Logistics  System  Modernization 
Program  (LSMP)  and  CALS  objectives  indicate  a  number  of  actions  that  DLA  can 
take  to  improve  its  productivity  and  responsiveness  to  the  Services’  provisioning 
needs. 

•  In  the  near-term,  DLA  needs  to  focus  on  implementing  the  automated 
capability  shown  in  the  PPP  demonstration.  It  must  integrate  those  actions 
with  development  and  implementation  of  the  Cataloging  Tools  On  Line 
(CTOL)  program.  We  address  these  actions  in  this  chapter. 

•  Follow-on,  longer  term  actions  need  to  extend  beyond  preprovisioning  to 
address  the  migration  of  DLA  and  the  Services  toward  a  digital,  near¬ 
paperless  provisioning  environment.  Longer  term  provisioning  moderniza¬ 
tion  is  discussed  in  Chapter  5. 

NEAR-TERM  PREPROVISIONING  SYSTEM  DEVELOPMENT 

The  PPP  demonstration  provides  a  baseline  system  upon  which  functional  and 
system  design  enhancements  and  extensions  should  be  incorporated  in  the  near- 
term.  Those  system  design  enhancements  and  extensions  that  we  recommend  be 
made  as  part  of  the  near-term  transition  to  an  operational  environment  are 
described  in  Chapter  3  and  summarized  in  Table  4-1. 

Consistent  with  the  Air  Force’s  involvement  in  the  PPP  demonstration,  we 
recommend  near-term  PPP  development  proceed  with  Air  Force  participation  and 
later  be  expanded  to  include  the  other  Services. 

Near-Term  System  Development  Plan 

In  this  section,  we  address  technical  and  organizational  issues  that  require 
planning  and  coordination  to  ensure  efficient  PPP  development  and  implementation. 
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Figure  4-1,  a  proposed  PPP  development  plan,  graphically  displays  the  major  actions 
and  milestones  that  we  recommend  for  the  near-term  to  achieve  a  full  production 
capability. 


TABLE  4-1 

PREPROVIS!ONING  SYSTEM  DEVELOPMENT  REQUIREMENTS 


Enhancements 

Full-function  extensions 

Quick  look-up  capability  with  windows 
PUCN  assignment  and  access 

Redefined  manager  functions 

Redundant  data  storage  elimination 
Z-STEM  communications  software  use 
Screen  layout  modification 

Data  transmission  speed  improvement 

Multiple  center  processing 

Simultaneous  processing  of  multiple  contracts 

Tape  loading  procedures  expansion 

Reports  and  management  information  expansion 
Database  security  enhancement 

DLSC  DIDS  i  nterface 

We  have  categorized  these  actions  and  milestones  into  the  phases  system 
preparation,  system  development  and  testing,  and  system  implementation.  The 
following  describes  the  three  phases. 

System  Preparation 

System  preparation  includes  obtaining  the  following  support: 

•  Near-term  hardware  and  software  support.  Hardware  and  software  support 
must  be  obtained  to  move  the  PPP  demonstration  off  the  DLA  DAITC 
ELXSI 6400  computer  and  obtain  sufficient  workstations  for  full  production 
capability.  To  continue  ease  of  implementation,  we  recommend  the  follow¬ 
ing  hardware  and  software  for  the  host  environment  and  DSCs: 

►  Host  environment. 

-  Host  computer  with  500  megabytes  (Mb)  of  mass  storage  (based  on  an 
average  10  Mb  of  data  per  contract  and  up  to  50  contracts  being 
processed  simultaneously). 

-  UNIX  operating  system. 

-  UNIFY™  database  management  system. 
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FIG.  4-1 .  PPP  SYSTEM  DEVELOPMENT  PLAN 


-  ACCELL™  database  application  development  software. 

-  ASCENT™  gateway  software. 

-  9600-baud  telecommunications  resources  to  support  dedicated  lines 
for  four  DLA  hardware  centers,  each  supporting  four  concurrent  user 
sessions.  One  dedicated  line  will  also  be  needed  for  system  adminis¬ 
tration  and  development  if  these  functions  are  performed  by  an 
activity  remote  from  the  host  computer  site. 

-  Structured  Query  Language  (SQL)  software  to  support  user  reports 
and  statistics  queries. 

-  Windowing  software. 

►  DLA  workstations  [four  at  each  DLA  hardware  center  —  DCSC,  DISC, 

Defense  General  Supply  Center  (DGSC),  and  Defense  Electronics  Supply 

Center  (DESC)]  standard  Z-248  configuration  with  the  following  fea¬ 
tures: 

-  Intel  80286  microprocessor. 

-  IBM  PC/AT  compatible  Basic  Input-Output  System  (BIOS). 

-  640  kilobytes  (kb)  random  access  memory  (RAM)  —  diskette 
controller  and  5i  inch  kb  diskette. 

-  Hard  disk  controller  and  20  Mb  drive. 

-  Monochrome  graphics  controller. 

-  Monochrome  monitor  with  full  80  X  24  display. 

-  Parallel  printer  port  and  80-column  printer.  Standard  issue  dot 
matrix  will  suffice. 

-  Keyboard. 

-  Support  chips,  bus  connects,  cabling,  and  all  other  pieces  and  parts 
required  for  a  functioning  system. 

-  MS-DOS,  Version  3.21. 

-  Communications  software  with  VT  220/300  emulation.  Z-STEM  is 
recommended. 

•  Military  Service  Support.  DLA  should  seek  continued  Air  Force  coopera¬ 
tion.  That  support  should  build  upon  the  cooperative  efforts  of  the  initial 
demonstration  to  further  develop  interfaces  and  refinements  to  PPP  and  the 
Air  Force  Logistics  Command  Mechanized  Provisioning  System. 
Additionally,  this  joint  DLA/ Air  Force  effort  could  be  broadened  to  include 
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participation  of  other  Services/agencies  once  PPP  has  matured.  A 
Memorandum  of  Understanding  (MOU)  between  the  Air  Force  and  DLA 
would  be  an  appropriate  vehicle  for  formalizing  this  joint  effort.  The  MOU 
could  be  expanded  to  include  other  participants  at  a  later  date.  (Including 
other  participants  subsequent  to  implementing  the  PPP  will  require  only 
the  program  which  extracts  data  from  the  Services’  magnetic  tape  to  be 
modified.  No  PPP  functions  or  cataloger  options  will  require  modification.) 

The  MOU  should  establish  the  necessary  framework  for  direct  access  to  the 
Air  Force’s  D220  Mechanized  Provisioning  System  consistent  with  PPP 
upgrade  efforts. 

System  Development  and  Testing 

Approximately  1  year  will  be  required  to  develop  software  for  a  full  production 
capability.  The  software  development  will  include  the  following  activities: 

•  Validation  of  the  basic  PPP  architecture. 

•  Preparation  of  a  final  PPP  specification. 

•  Development  and  testing  of  hardware  and  software  modifications  and 
enhancements  noted  in  Table  4-1. 

•  Follow-on  Development  and  Integration  of  the  Computer  System 
Architecture.  The  prototype  computer  system  architecture  uses  a  central 
host  computer  with  remote  processing  at  "dumb”  terminals.  In  the  near- 
term,  that  configuration  can  be  used.  An  alternative,  a  distributed 
processing  environment,  appears  to  be  consistent  with  longer  term  goals 
associated  with  transition  to  a  near  paperless  environment,  particularly 
with  regard  to  the  use  of  graphics  and  expanding  data  transmission  require¬ 
ments.  A  distributed  processing  system  would  still  employ  a  central  host 
computer  but  would  be  capable  of  supporting  a  number  of  remote  processing 
functions  using  "smart”  terminals  with  both  a  text  and  graphics  capability. 
In  the  near-term,  DLA  should  examine  alternative  computer  system 
architectures,  including  the  feasibility  of  using  the  text-graphics  work¬ 
stations  that  will  be  available  under  the  CTOL  acquisition. 

System  Implementation 

System  implementation  includes  the  following  actions: 

•  Migrating  the  host  computer  environment  to  DCSC 

•  Installing  the  PPP  at  the  remaining  DLA  centers  (DISC,  DGSC,  and 
DESC). 
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Provisioning  Integration  Center 

To  facilitate  the  near-,  mid-,  and  long-term  development  of  the  PPP,  we 
recommend  that  DLA  implement  a  PIC  that  would  be  the  focal  point  for  coordinating 
DLA  preprovisioning  efforts. 

The  first  PPP  implemented  at  a  DLA  center  will  constitute  the  baseline  for 
subsequent  sites  and  ultimate  transfer  of  provisioning  system  technology  and 
processes  throughout  the  Defense  establishment  and  industry.  DCSC,  the  first  PPP 
site,  will  serve  as  the  primary  DLA  headquarters  agent  to  coordinate  both  PPP 
operations  and  follow-on  developmental  and  system  enhancements.  Additionally, 
DCSC  has  been  the  demonstration  site  for  the  CTOL  workstation  and  other 
innovative  technological  initiatives.  Thus,  we  recommend  DCSC  be  designated  as 
the  PIC. 

The  technical  objectives  of  the  PIC  are  as  follows: 

•  In  the  near-term  PPP  phases  of  system  development  and  test 

►  Validate  preprovisioning  system  architecture  and  procedures 
t  Provide  an  initial  preprovisioning  capability 

•  In  the  mid-  and  long-term,  develop  mechanisms  for  facilitating  the 
upgrading  of  technology  and  procedures  for  existing  provisioning  methods 
and  associated  automated  processes  for  transition  to  a  digital  environment. 

The  operational  objective  of  the  PIC  is  to  centralize  administrative  control  of 
the  following  tasks: 

•  Providing  a  single  interface  between  the  Services  and  the  DSCs 

•  Receiving  technical  data  from  contractors  and  the  Services  and  distributing 
those  data  to  other  DSCs  as  required 

•  Assigning  FSCs  to  designated  DSCs  for  each  SSR  received  from  a  Service. 
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CHAPTER  5 


PREPROVISIONING  MODERNIZATION  WITH  EMERGING 

CALS  ENVIRONMENT 


GENERAL 

The  CALS  initiative  focuses  on  the  application  of  current  and  emerging 
computer  and  telecommunications  technology  to  significantly  reduce  the  cost  and 
improve  the  effectiveness  of  designing,  producing,  and  supporting  weapon  systems 
and  equipment.  CALS-related  demonstration  efforts  in  DLA,  the  Services,  and 
industry  are  expected  to  automate  many  traditional  paper-based  processes  for 
handling  data  products  such  as  engineering  drawings,  technical  manuals,  and 
logistic  support  analysis  (LSA)  reports.  Contractor-delivered  digital  document 
image  files  and  the  conversion  of  stored  documentation  to  digital  form  will  provide  a 
print  or  display-on-demand  capability  for  most  applications. 

CALS  TARGET  CAPABILITIES  FOR  THE  1990s 

Each  of  the  Services  and  DLA  has  established  a  CALS  program  and  plans  to 
transition  to  a  digital  technical  information  environment.  Target  capabilities  that 
have  been  identified  generally  include  the  following. 

•  Streamline  and  integrate  selected  weapon  system  design  and  logistic 
support  functions,  including  the  following: 

t  The  capability  to  integrate  logistics  technical  information  from  a 
number  of  databases 

>  The  capability  to  integrate  quantitative  reliability  and  maintainability 
(R&M)  requirements  into  design  and  design  analysis  processes. 

•  Minimize  data  redundancy  and  maximize  data  integrity,  consistency,  and 
traceability,  including  the  following: 

t  The  capability  to  maintain  weapon  system  configuration  data  on  a  near- 
real-time  basis 

t  The  capability  for  automated  updating  of  data  based  upon  changes  in 
weapon  system  design. 
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•  Increase  effectiveness  and  efficiency  in  the  exchange  of  technical  informa¬ 
tion  including  the  following: 

>  The  capability  to  store,  retrieve,  distribute,  and  process  technical 
information  in  paperless  form 

►  The  capability  to  provide  users  with  access  to  data  from  multiple 
sources. 

TRANSITION  TO  A  DIGITAL  ENVIRONMENT 

The  transition  from  hard  copy  to  digital  media  will  require  cooperation  from 
industry,  the  Services,  and  DLA  to  use  state-of-the-art  digital  hardware  and  soft¬ 
ware  in  performing  three  major  functions: 

•  Automating  and  integrating  the  production  of  data  (e.g.,  through  CAD  or 
automated  authoring  systems) 

•  Storing  and  retrieving  data  in  digital  form 

•  Distributing  and  using  the  data  in  digital  form. 

The  media  of  paper,  film,  and  digital  will  coexist  during  the  transition  to  a 
near-paperless  environment.  In  fact,  some  applications  may  rely  on  paper  outputs 
indefinitely.  Some  small  Defense  contractors  may  be  unable  to  make  the  transition 
to  a  wholly  digital  environment  and  will  require  drawings  and  data  in  paper  or 
microform  copy  if  they  are  to  continue  participating  in  the  competitive  bidding 
process.  Alternatively,  the  possibility  exists  that  contractors  could  be  hired  to 
provide  these  small  Defense  contractors  with  digital  capabilities. 

Reductions  in  the  use  of  paper  will  be  realized  initially  when  repositories  of 
existing  technical  information  are  converted  to  digital  form  and  a  print-on-demand 
capability  is  fully  operational.  Further  reductions  in  paper  will  occur  as  contractor¬ 
generated  data  are  processed,  reviewed,  and  received  by  the  Services  in  digital  form 
and  data  products  (i.e.,  engineering  drawings  and  associated  lists)  are  distributed  in 
digital  form.  An  accompanying  evolution  of  digital  data  standards,  such  as  the 
Product  Data  Exchange  Specification  (PDES),  will  provide  the  opportunity  to  move 
beyond  the  presentation  of  data  in  traditional  products,  such  as  standard  reports,  to 
an  environment  in  which  data  can  be  displayed  on  demand  to  match  the  precise  task 
being  performed. 
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PROVISIONING  MODERNIZATION 

The  evolving  CALS  environment  establishes  a  framework  for  comprehensive 
modernization  of  the  provisioning  process.  Five  fundamental  objectives  for  this 
effort  are 

•  To  reduce  PALT  support  to  the  Services 

•  To  shorten  the  provisioning  research  process  by  creating  and  assembling 
the  right  information 

•  To  assist  and  simplify  the  provisioning  decision-making  process 

•  To  decrease  the  amount  of  time  and  effort  for  provisioning  source  coding 
conferences  or  eliminate  the  conferences  altogether 

•  To  process  Services  SSRs  electronically. 

Achieving  these  objectives  involves  cooperative  effort  by  the  Services,  DLA, 
and  Defense  contractors.  Current  progress  in  such  areas  as  artificial  intelligence, 
computer-aided  engineering  (CAE),  CAD,  computer-aided  manufacturing  (CAM), 
automated  LSAR,  advanced  product  data  models,  and  data  communications  all  affect 
the  future  direction  of  provisioning.  The  proposed  PIC  should  be  the  focal  point  for 
streamlining  and  integrating  the  provisioning  process.  The  PIC  should  ensure  that 
the  capabilities  implemented  by  DLA  meet  customer  requirements  and  are 
compatible  with  the  technologies  adopted  by  both  industry  and  the  Services. 
Establishing  the  PIC  would  put  DLA  at  the  forefront  of  the  provisioning 
modernization  process.  Such  a  role  is  not  intended  to  (nor  will  it)  alter  Service 
responsibilities  for  equipping  and  supplying  their  forces.  It  does,  however,  recognize 
that  DLA  is  the  major  supplier  within  DoD.  Approximately  58  percent  of  common 
piece  parts  used  by  the  Services  are  cataloged  and  managed  by  DLA. 

The  PIC  could  also  serve  as  part  of  the  CALS  Testbed  Network  for  developing 
and  validating  proposed  provisioning  enhancements  accruing  from  CALS  and  other 
logistics  modernization  efforts.  Some  of  the  more  significant  areas  for  which  the  PIC 
could  provide  development  and  validation  assistance  are  shown  in  Table  5-1. 
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TABLE  5-1 


PROVISIONING  MODERNIZATION  1991  -  2001 


Primary  thrust 

Activity 

Impact 

Implementation 

a  Increased  use  of  CAE/CAD 

Industry 

•  More  accurate  parts  representation 

•  Greater  use  of  standardized  parts 

•  Drawing  adequacy  review  reduced  or  elim  inated 

a  Automate  technical  data 

OLA,  Services 

•  More  accessible  data 

repositories 

a  Hard  copy  data  exchange 

•  Integrated  weapon  system 
data  management 

Services 

•  More  accurate  requirements  forecasts 

Development 

•  Enhanced  automated 

ISAR 

Industry,  Services, 
OLA 

•  Redundancy  of  support  data  reduced  or  eliminated 

•  Expanded  data  comm  uni- 
cations 

OCA,  Services, 

DLA 

•  Data  reviewed  and  approved  on-line 

•  Provisioning  knowledge 

Industry,  Services, 

•  Collective  provisioner/cataloger  skills  and  experience 

engineering  systems 

OLA 

facilitate  decisionmaking 

•tot*.  OCA  *  Defense  Communications  Agency. 


Major  near-,  mid-,  and  long-term  milestones  for  fully  integrating  the  PPP  are 
shown  in  Figure  5-1.  The  PPP  development  plan  and  operations  are  discussed  in 
Chapter  4  of  this  report.  It  focuses  on  achieving  an  initial  production  capability.  In 
the  mid-  to  long-term,  PPP  interfaces  should  be  established  with  CTOL,  DIDS, 
Engineering  Data  Management  Information  and  Control  System  (EDMICS),  other 
Services  and  contractor  databases.  Additionally,  PPP  modernization  initiatives  will 
permit  DLA  to 

•  Process  SSRs  in  electronic  form 

•  Perform  electronic  source  coding  with  Services 

•  Play  an  active  role  in  Service  contract  data  calls. 
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DLA  Role  in  Initial  Provisioning  Process 

The  merits  of  DLA  participating  in  the  provisioning  process  prior  to  the 
traditional  provisioning  conference  are  discussed  in  Chapter  3.  However,  in  a  paper- 
based  process,  the  provisioning  conference  is  necessary,  and  it  occurs  well  into  the 
weapon  system  development  process. 

We  believe  active  DLA  participation  in  the  initial  phases  of  a  weapon  system 
acquisition  should  occur  well  before  the  provisioning  conference,  particularly  when 
data  exchanges  are  expedited  between  the  Services  and  contractors,  either  through 
digital  media  or  direct  on-line  access.  In  the  following  two  specific  areas,  existing 
procedures  must  be  significantly  adjusted  in  an  anticipatory  (proactive)  DLA 
provisioning  management  role: 

•  Contract  development.  Ideally,  DLA  would  participate  with  the  Services  to 
ensure  that  contract  language  for  development,  procurement,  and  access  to 
technical  and  other  data  used  in  provisioning  meets  both  Service  and  DLA 
requirements  as  it  is  generated  (no  Service  repackaging  would  be  required 
for  DLA  use).  DLA  would  participate  in  the  Services’  contract  data  calls 
and  would  have  the  authority  to  interact  directly  with  the  contractor. 
Direct  DLA-contractor  interaction  would  focus  on  identifying  in  the 
contract  the  full  range  of  engineering  drawings  and  associated  technical 
data  required  to  support  provisioning/cataloging. 

•  Provisioning  planning  and  guidance  conferences.  DLA  participation  in 
initial  Service  provisioning  planning  and  guidance  conferences  should  be 
initiated  to  provide  the  opportunity  for  continued  cooperative  effort  and 
awareness  by  DLA  and  the  Service  regarding  the  following  typical  issues: 

►  Task  and  funding  milestones 

►  Commitments  for  optional  requirements 

►  Contractual  provisioning  requirements 

►  Operational  and  maintenance  concepts 
t  Provisioning  techniques  to  be  used 

t  Provisioning  screening  requirements 

►  Item  identification  and  data  preparation 

►  Design  change  notices 
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>  Delivery  schedules 

►  Interim  support  requirements. 

Note:  We  recognize  that  DLA  may  find  it  impractical  to  provide  equal  coverage 
to  all  acquisition  contracts  and  all  provisioning  planning  and  guidance  conferences. 
Mutually  agreeable  attendance  criteria  should  be  the  subject  of  joint  DLA/Military 
Services  arrangement.  The  key  issue  is  that  failure  to  consider  an  early,  active  DLA 
role  ignores  the  fundamental  joint  (Services  and  DLA)  nature  of  the  provisioning 
process. 

DLA  Access  to  Provisioning  Data 

Services  with  on-line  access  to  contractor  databases  are  already  experiencing 
rapid  turnaround  for  design  changes  and  approvals.  Since  DLA  does  not  now  have 
visibility  into  this  process,  its  required  item  identification,  item  entry  control,  and 
item  management  actions  must  await  sequential  processing  and  generation  of  an 
SSR  by  the  Services. 

DLA  could  have  on-line  access  to  the  initial  provisioning  process  early  on 
through 

•  DoD  automated  provisioning  systems  and  provisioning-related  databases 

•  Contractor  automated  provisioning  and  LSAR  databases. 

Examples  of  DoD  automated  provisioning  systems  and  provisioning-related 
databases  available  to  DLA  are 

•  Service  provisioning  data  system.  A  near-term  provisioning  enhancement 
could  be  realized  by  DLA  accessing  the  Air  Force  D220  automated 
provisioning  system.  On-line  access  accompanied  by  bulk  data  downloading 
to  the  DLA  PPP  would  provide  necessary  data  to  DLA.  A  similar  process 
could  be  initiated  between  the  DLA  CTOL  system  and  the  Services 
automated  data  repository  systems  to  obtain  SPTD  (i.e.,  engineering 
drawings,  sketches,  and  schematics).  On-line  access  to  both  initial 
provisioning  and  SPTD  would  enable  DLA  to  rapidly  identify  items  and 
perform  initial  screening  tasks  directly  with  the  Services’  provisioning 
databases.  Following  DLA  item  identification  and  initial  screening,  the 
Se  rvice  would  review  and  approve  DLA  inputs,  using  the  database  rather 
than  a  listing  or  report  derived  from  the  database.  That  procedure  can 
accelerate  the  provisioning  coding  process  to  a  degree  that  will  significantly 
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reduce  or  possibly  eliminate  the  requirement  for  traditional  source  coding 
conferences. 

•  DIDS  TIR  access .  The  DIDS  contains  fully  descriptive  technical  informa¬ 
tion  on  stocklisted  items  in  its  TIR  Hie.  On-line  access  to  these  data  by 
industry,  the  Services,  and  DLA  activities  will  facilitate  accurate  first-time 
item  identification,  screening,  and  I&S  evaluation. 

Examples  of  contractor  automated  databases  from  which  DLA  could  benefit 
through  on-line  access  are 

•  Logistics  and  procurement  data  access.  Early  expansion  of  on-line  access 
capabilities  to  the  provisioning  process  could  be  realized  as  an  outgrowth  of 
current  Service  efforts  such  as  that  at  the  Navy’s  Aviation  Supply  Office 
(ASO).  Currently,  ASO  has  on-line  access  to  the  logistics  and  procurement 
files  of  seven  major  Defense  contractors  for  the  following  types  of  data: 

k  Manufacturing  sources 

k  Material  sources 

k  Bill  of  material  for  TDBD 

k  Make-or-buy  data 

k  Functional  test  requirements 

k  Technical  data  revision  status. 

The  following  potential  benefits  accrue  from  making  the  types  of  source 
data  included  in  this  application  available  to  end  users: 

t  Access  to  the  most  current  data  is  ensured  because  data  ownership  and 
configuration  control  are  maintained  by  the  contractor. 

►  Redundant  data  processing  and  handling  can  be  minimized  because 
source  data  rather  than  regenerated  data  are  used. 

•  LSAR  data.  By  the  mid-1990s,  most  major  contractors  will  have  developed 
or  purchased  enhanced  LSAR  data-processing  systems.  Accompanying 
technology  upgrades  are  expected  to  include  on-line  interface  with  other 
corporate  data  files  of  significant  design  and  support  data.  The  result  will 
be  an  integrated,  on-line  database  and  necessary  software  that  could  serve 
both  Military  Service  and  DLA  needs  in  initial  outfitting  and  provisioning. 


5-8 


DLA  Role  Subsequent  to  Initial  Provisioning 

In  addition  to  the  benefits  available  to  DLA  through  on-line  access  to  DoD  and 
contractor  databases  in  the  provisioning  process,  DLA  should  also  have  on-line 
access  to  the  following  types  of  data: 

•  Parts  usage  data.  Data  aggregated  in  Service  materiel  forecasting  and 
inventory  management  systems  are  utilized  internally  within  the  Services 
to  determine  changes  in  supply  support  requirements.  The  Services’ 
subsequent  submittal  of  SSRs  currently  notifies  DLA  of  their  support 
requirements.  Early  DLA  visibility  to  the  Services’  parts  usage  data  would 
permit  more-timely  assessment  of  current  inventory  levels  and  anticipated 
demands. 

•  Configuration  status  accounting  and  design  change  data.  Currently,  the 
process  of  weapon  system  design  change  and  system  retrofit  takes  place 
exclusively  within  the  design  and  engineering  activities  of  the  Services. 
Design  changes  and  system  retrofitting  only  become  visible  to  cognizant 
Service  supply  activities  when  the  design  and  engineering  activities  submit 
applicable  Design  Change  Notices  (DCNs).  DLA  obtains  visibility  of  a 
given  design  change  only  after  the  Service  supply  activity  submits  an  SSR. 

Even  though  efforts  within  the  Services  to  link  design  change  and  support 
processes  more  closely  should  reduce  time  lags  for  generating  SSRs,  DLA  should 
have  access  to  DCNs.  Timely  DLA  visibility  to  DCNs  (preferably  when  released  to 
the  Service  supply  organization)  would  give  DLA  the  opportunity  to  evaluate  the 
inventory  status  and  project  aggregate  demand  changes  early  in  the  provisioning 
process  and  would  result  in  maximized  DLA  supply  support  to  Service  requirements. 
That  timely  visibility  is  especially  important  when  we  consider  that  significant 
requirements  for  additional  DLA  supply  support  will  occur  as  modifications  and 
upgrades  are  made  to  the  70—80  percent  of  current  weapon  systems  expected  to  still 
be  deployed  in  the  post-2000  timeframe. 

PROVISIONING  TRANSITION  TO  A  DIGITAL  ENVIRONMENT 

The  CALS  initiative  provides  the  umbrella  under  which  cataloging  and 
provisioning  can  be  streamlined  to  reduce  the  Services’  requirement  to  participate  in 
the  cataloging  process  and  ultimately  to  eliminate  that  requirement  entirely.  DLA 
and  the  contractor  rather  than  the  Services  would  perform  the  cataloging  functions. 
Early  visibility  of  each  Service  and  DLA  to  each  other’s  databases  for  design, 
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support,  and  maintenance  feedback  would  hasten  the  process.  Continuous  updating 
of  Service  databases  will  permit  suppliers  to  approve  and  use  the  data. 

With  data  accessibility  and  advanced  inventory  modeling  techniques,  DLA  can 
streamline  and  improve  item  management  in  a  similar  fashion.  Visibility  to 
changes  in  program  status,  usage  rates,  configuration  status,  and  other  relevant 
data  will  enable  the  Services  and  DLA  to  perform  supply  and  resupply  operations 
simultaneously  rather  than  sequentially.  That  is,  inventory  management  and 
requirements  forecasting  will  evolve  into  a  coordinated  Service/DLA  process  that 
can  respond  proactively  to  the  needs  of  the  operating  forces. 

SUMMARY 

General 

The  PPP  system  demonstration  has  verified  that  the  application  of  computer 
technology  to  the  provisioning  process  affords  a  significant  opportunity  to  improve 
productivity  and  increase  the  effectiveness  of  DLA  operations  in  support  of  the 
Services  and  other  Defense  agencies.  It  also  showed  significant  opportunities  for 
capitalizing  on  emerging  CALS  data  exchange  standards  and  other  ongoing  CALS 
initiatives  to  streamline  provisioning  and  cataloging  processes. 

Cataloging  and  Provisioning  Modernization 

We  recommend  that  DLA  develop  the  PPP  to  a  full  production  system;  the 
major  initiatives  needed  to  do  so  are  shown  in  Table  5-2.  Implementation  of  our 
recommendation  means  establishing  a  fully  operational  PPP  capability  at  the  four 
DSCs  during  FY90. 

The  first  PPP  site  at  DCSC  is  proposed  as  a  PIC,  a  focal  point  for  coordinating 
follow-on  modernization  efforts  among  DLA,  the  Services,  and  Defense  contractors. 
The  PIC  puts  DLA  in  a  leading  role  to  influence  modernization  of  cataloging  and 
provisioning  processes. 


TABLE  5-2 


PPP  MODERNIZATION  INITIATIVES  1990  -  2001 


Action 

Purpose 

Implementation 

Establish  PIC 

Test  and  validate  functional  and  technical 
interfaces 

Integrate  preprovisioning  with  CTOL  and 

DIDS 

Shorten  research  process 

Establish  logistics  data  gateway  environment 

Access  to  Service  and  contractor  databases 
(provisioning,  LSAR,  and  configuration  status) 

Development 

Develop  knowledge-based  systems 

Expedite  item  management  decisions 

Develop  CAE/CAD-based  tools 

Assist  in  l&S  evaluation 
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ALC 

= 

Air  Logistics  Center 

ASO 

— 

Aviation  Supply  Office 

bps 

= 

bits  per  second 

CAD 

= 

computer-aided  design 

CAE 

= 

computer-aided  engineering 

CAGE 

= 

contractor  and  Government  entity 

CALS 

— 

Computer-aided  Acquisition  and  Logistic  Support 

CAM 

= 

computer-aided  manufacturing 

CNID 

= 

contract  number  identification  code 

CTC 

= 

cataloger  technician  code 

CTOL 

= 

Cataloging  Tools  On  Line 

DAC 

= 

document  availability  code 

DAITC 

= 

Defense  Applied  Information  Technology  Center 

DCA 

— 

Defense  Communications  Agency 

DCN 

= 

Design  Change  Notice 

DCSC 

= 

Defense  Construction  Supply  Center 

DESC 

= 

Defense  Electronics  Supply  Center 

DGSC 

— 

Defense  General  Supply  Center 

DIDS 

= 

Defense  Integrated  Data  System 

DISC 

= 

Defense  Industrial  Supply  Center 

DLA 

= 

Defense  Logistics  Agency 

DLSC 

= 

Defense  Logistics  Services  Center 

DoD 

= 

Department  of  Defense 
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DSC 

EDMICS 

FSC 

I&S 

ICP 

kb 

LSA 

LSAR 

LSMP 

Mb 

MCM 

MEL-STD 

MOU 

NUN 

NSN 

P/N 

PALT 

PC 

PCB 

PCCN 

PDES 

PIC 

PHN 

PLICN 

PLISN 

PPL 

PPP 


=  Defense  Supply  Center 

=  Engineering  Data  Management  Information  and  Control  System 
=  Federal  Supply  Class 
=  interchangeability  and  substitutability 
=  inventory  control  point 
=  kilobyte 

=  logistic  support  analysis 
=  Logistic  Support  Analysis  Record 
=  Logistics  System  Modernization  Program 
=  megabyte 

=  Master  Contract  Matrix 
=  Military  Standard 
=  Memorandum  of  U  nders  tan  ding 
=  National  Item  Identification  Number 
=  National  Stock  Number 
=  part  number 

=  procurement  administrative  leadtime 
=  personal  computer 
=  Provisioning  Control  Branch 
=  Provisioning  Contract  Control  Number 
=  Product  Data  Exchange  Specification 
=  Provisioning  Integration  Center 
=  Procurement  Instrument  Identification  Number 
=  PLISN/PCCN/SCC 
=  Provisioning  List  Item  Sequence  Number 
=  Provisioning  Parts  List 
=  Preprovisioning  Prototype 
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PPR 

— 

Provisioning  Parts  Record 

PSR 

= 

provisioning  screening  results 

PTD 

= 

provisioning  technical  documentation 

QUP 

= 

quantity  unit  pack 

R&M 

— 

reliability  and  maintainability 

RAM 

= 

random  access  memory 

RDT&E 

= 

research,  development,  test,  and  evaluation 

RNCC 

= 

reference  number  category  code 

see 

= 

Submission  Control  Code 

SPTD 

= 

supplementary  provisioning  technical  documentation 

SQL 

— 

Structured  Query  Language 

SSR 

= 

supply  support  request 

TDBD 

= 

Top  Down  Breakdown 

TIR 

= 

Total  Item  Record 

U/I 

= 

unit  of  issue 
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MASTER  CONTRACT  MATRIX  ESTABLISHMENT 

INTRODUCTION 

The  Master  Contract  Matrix  (MCM)  function  establishes  the  submission 
identification  data  file.  Each  record  in  the  MCM  is  established  by  either  the 
cataloger  or  the  Preprovisioning  Prototype  (PPP)  during  the  validation  step  of  the 
data  submitted  to  the  Defense  Construction  Supply  Center.  The  cataloger  can 
establish  this  record.  The  system  either  completes  the  record  established  by  the 
cataloger  or  builds  the  entire  data  record  from  information  recorded  in  the  header 
information  of  the  Air  Logistics  Center  (ALC)-submitted  data.  The  cataloger  can 
view,  query,  and  update  this  file  through  an  on-line,  menu-driven  capability. 
Interactive  and  off-line  updates  are  also  made  to  this  file  as  a  result  of  interactive 
and  off-line  processing  of  the  PLICN  [Provisioning  List  Item  Sequence  Number 
(PLISNVProvisioning  Contract  Control  Number  (PCCN)/Submission  Control  Code 
(SCC)]  file. 

Process  Supporting  the  Master  Contract  Matrix  Establishment 

Figures  A-l  and  A-2  depict  the  processes  that  support  establishing  the  MCM. 

The  MCM  comprises  the  following  three  segments: 

•  Segment  1 

►  Procurement  Instrument  Identification  N umber  (PEN) 

►  Prime  contractor  identification  data 

•  Segment  2 

►  PCCN 

►  Provisioning  Parts  List  (PPL)  due  date 

►  Nomenclature  type 


Provwwung  Conuol  Bnnth:  (“*>*  *  Pfcwiitoning  Recofd.  PTD  *  pfoviuonmg  t«hn«»t  documentation 

FIG.  A-1 .  ESTABLISHMENT  OF  MASTER  CONTRACT  MATRIX  FILE 


FIG.  A-2.  MAINTAIN  MASTER  CONTRACT  MATRIX  FILE 


•  Segment  3 

►  SCC 

►  Management  data. 

One  or  more  Segments  2  can  be  associated  with  each  Segment  1,  and  one  or 
more  Segments  3  can  be  associated  with  each  Segment  2. 

Upon  receipt  of  PPL  data  [Provisioning  Parts  Record  (PPR)  file]  from  the  ALC, 
the  PPP  performs  the  following  actions: 

•  Searches  Segment  2  by  PCCN  (from  PPR  file). 

►  If  the  PCCN  is  not  found  in  the  MCM,  the  PPP  searches  the  Segment  1 
data  file  for  a  matching  PUN. 

-  If  the  PHN  is  already  recorded,  it  builds  Segment  2  for  a  new  PCCN 
(using  the  PCCN  from  the  PPR  file). 

-  If  the  PHN  is  not  recorded,  it  builds  a  Segment  1  from  information 
provided  on  the  PPR  file  and  builds  Segment  2  for  the  new  PCCN. 
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>  If  the  PCCN  is  found  in  the  MCM,  the  PPP  searches  Segment  1  for  the 
PEN. 

t  If  the  PEN  is  not  detected  in  the  MCM,  the  PPP  notifies  the  cataloger  of 
a  possible  PEN  error. 

•  Searches  Segment  3  data  file  by  SCC. 

>  E  the  SCC  is  not  recorded,  the  PPP  builds  the  Segment  3  data  set  and 
assigns  it  to  a  cataloger. 

t  E  the  SCC  is  recorded,  the  PPP  checks  the  Date  PPL  Received  field  in  the 
MCM. 

-  E  the  field  is  blank,  the  PPP  adds  data  elements  to  the  MCM  record. 
A  blank  Date  PPL  Received  field  indicates  that  the  file  was  created 
manually.  The  cataloger  may  not  have  had  all  the  information 
required  for  Segments  1,  2,  or  3.  The  system  now  fills  in  the  missing 
data  in  the  MCM  from  the  PPR  header  record. 

-  E  the  field  is  not  blank,  the  PPP  notifies  the  cataloger  of  a  potential 
duplicate  submission.  The  cataloger  has  the  capability  to  compare 
the  incoming  MCM  identification  data  with  the  existing  MCM  file 
and  to  delete  a  duplicate  submission. 

•  Assigns  a  contract  number  identification  code  (CNID).  When  the  SCC  is 
recorded  in  the  MCM,  the  PPP  assigns  a  three-position  CNID  to  the  MCM 
record.  That  code  is  used  to  identify  the  PEN,  PCCN,  and  SCC  for  each 
PUCN  record  in  the  history  file.  It  reduces  the  size  of  identification  data  for 
individual  PLICN  history  records.  (Since  the  SCC  must  be  automatically 
entered  upon  receipt  of  provisioning  technical  documentation  from  the 
ALC,  the  CNID  should  also  be  assigned  at  that  time.) 


A-4 


